It is important to be able to perform path identification for a network for the following purposes: in the case of an Internet Protocol (IP) network, for example, to check whether a path that was set during the design of the network corresponds to an actual path; and in the case of a service such as Voice over Internet Protocol (VoIP), to find out, after occurrence of a quality deterioration, which path an influential flow passes through and to check, when performing a network reconstruction, whether a path is appropriately bypassed so that the service will not be affected. In order to perform path control for an IP network, for example, an Open Shortest Path First (OSPF) protocol is used. In the OSPF protocol, path control information called “link-state advertisements (LSAs)” is exchanged between routers that form a network. By exchanging LSAs between routers, a routing table is constructed to perform path control for an IP network.
There may be a case in which, for example, in order to perform load distribution or the like in a network subjected to path control performed using the OSPF protocol, a path that is different from a path set using the OSPF protocol is statically set for a particular sub-network. Path information that has been statically set does not appear on the network in the form of LSAs of the OSPF protocol. Therefore, with an apparatus that monitors a path by obtaining LSAs in a similar manner to a router, only path information relating to a network set using the OSPF protocol can be obtained, and path information relating to a network that is actually managed cannot be obtained. For this reason, when performing a path identification for a network, it is important to obtain path information concerning a path that is statically set and match the path information to path information relating to a network that is actually managed.
In order to obtain statically set path information, to date, for example, the following has been performed: a management information base (MIB) of routing tables of all routers has been obtained; a check using a command has been performed after login; or tracing of a path has been executed between source and destination addresses and the results have been compared with the calculation results in the OSPF protocol so as to find out a different path. In these methods, because entries of routing tables of all routers need to be found or paths of all source and destination flows need to be traced and checked, a router that cannot be accessed, if any, cannot be detected or the check may take time to execute tracing for all the source and destination flows.
Japanese Laid-open Patent Publication No. 2008-061139 is an example of related art.